Mobile Telecommunications Protocols For Data Networks. Anna Hac 
Copyright © 2003 John Wiley & Sons, Ltd. 

ISBN: 0-470-85056-6 



MOBILE 

TELECOMMUNICATIONS 
PROTOCOLS FOR 
DATA NETWORKS 




MOBILE 

TELECOMMUNICATIONS 
PROTOCOLS FOR 
DATA NETWORKS 

Anna Hac 

University of Hawaii at Manoa, Honolulu 




JOHN WILEY & SONS, LTD 




Copyright © 2003 



John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, 
West Sussex P019 8SQ, England 



Telephone (+44) 1243 779777 

Email (for orders and customer service enquiries): cs-books@wiley.co.uk 
Visit our Home Page on www.wileyeurope.com or www.wiley.com 

All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or 
transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or 
otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of 
a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London WIT 4LP, 
UK, without the permission in writing of the Publisher. Requests to the Publisher should be addressed 
to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West 
Sussex P019 8SQ, England, or emailed to permreq@wiley.co.uk, or faxed to (+44) 1243 770571. 

This publication is designed to provide accurate and authoritative information in regard to the subject 
matter covered. It is sold on the understanding that the Publisher is not engaged in rendering 
professional services. If professional advice or other expert assistance is required, the services of a 
competent professional should be sought. 



Other Wiley Editorial Offices 

John Wiley & Sons Inc., Ill River Street, Hoboken, NJ 07030, USA 

Jossey-Bass, 989 Market Street, San Francisco, CA 94103-1741, USA 

Wiley-VCH Verlag GmbH, Boschstr. 12, D-69469 Weinheim, Germany 

John Wiley & Sons Australia Ltd, 33 Park Road, Milton, Queensland 4064, Australia 

John Wiley & Sons (Asia) Pte Ltd, 2 Clementi Loop #02-01, Jin Xing Distripark, Singapore 129809 

John Wiley & Sons Canada Ltd, 22 Worcester Road, Etobicoke, Ontario, Canada M9W 1L1 



British Library Cataloguing in Publication Data 
A catalogue record for this book is available from the British Library 
ISBN 0-470-85056-6 

Typeset in 10/12pt Times by Laserwords Private Limited, Chennai, India 

Printed and bound in Great Britain by TJ International, Padstow, Cornwall 

This book is printed on acid-free paper responsibly manufactured from sustainable forestry 

in which at least two trees are planted for each one used for paper production. 




Contents 



Preface ix 

About the Author xiii 

1 Mobile Agent Platforms and Systems 1 

1.1 Mobile Agent Platforms 1 

1.1.1 Grasshopper 2 

1.1.2 Aglets 2 

1.1.3 Concordia 3 

1.1.4 Voyager 3 

1.1.5 Odyssey 3 

1.2 Multiagent Systems 3 

1.2.1 Agent-based load control strategies 5 

1.3 Summary 9 

Problems to Chapter 1 10 

2 Mobile Agent-based Service Implementation, Middleware, 

and Configuration 11 

2. 1 Agent-based Service Implementation 1 1 

2.2 Agent-based Middleware 17 

2.3 Mobile Agent-based Service Configuration 23 

2.4 Mobile Agent Implementation 28 

2.5 Summary 29 

Problems to Chapter 2 29 

3 Wireless Local Area Networks 33 

3.1 Virtual LANs 33 

3.1.1 Workgroup management 35 

3.1.2 Multicast groups 36 

3.2 Wideband Wireless Local Access 37 

3.2.1 Wideband wireless data access based on OFDM 

and dynamic packet assignment 37 

3.2.2 Wireless services support in local multipoint distribution 

systems 39 





VI 



CONTENTS 



3.2.3 Media Access Control (MAC) protocols for wideband 

wireless local access 41 

3.2.4 IEEE 802.il 41 

3.2.5 ETSI HIPERLAN 44 

3.2.6 Dynamic slot assignment 46 

3.3 Summary 50 

Problems to Chapter 3 51 

4 Wireless Protocols 55 

4.1 Wireless Protocol Requirements 56 

4.2 MAC Protocol 56 

4.3 Broadband Radio Access Integrated Network 58 

4.4 Hybrid and Adaptive MAC Protocol 59 

4.5 Adaptive Request Channel Multiple Access Protocol 60 

4.6 Request/Acknowledgement Phase 61 

4.7 Permission/Transmission Phase 62 

4.8 Performance Analysis 65 

4.9 Performance Measures 67 

4.10 Summary 69 

Problems to Chapter 4 70 

5 Protocols for Wireless Applications 73 

5.1 Wireless Applications and Devices 73 

5.2 Mobile Access 79 

5.3 XML Protocol 80 

5.4 Data Encapsulation and Evolvability 82 

5.5 Wireless Application Protocol (WAP) 85 

5.6 Summary 88 

Problems to Chapter 5 89 

6 Network Architecture Supporting Wireless Applications 93 

6.1 WAE Architecture 93 

6.2 WTA Architecture 98 

6.3 WAP Push Architecture 105 

6.4 Summary 109 

Problems to Chapter 6 109 

7 XML, RDF, and CC/PP 111 

7.1 XML Document 111 

7.2 Resource Description Framework (RDF) 1 14 

7.3 CC/PP - User Side Framework for Content Negotiation 1 19 

7.4 CC/PP Exchange Protocol based on the HTTP Extension 

Framework 129 

7.5 Requirements for a CC/PP Framework, and the Architecture 132 





CONTENTS 



vii 



7.6 Summary 135 

Problems to Chapter 7 135 

8 Architecture of Wireless LANs 139 

8.1 Radio Frequency Systems 140 

8.2 Infrared Systems 141 

8.3 Spread Spectrum Implementation 141 

8.3.1 Direct sequence spread spectrum 141 

8.3.2 Frequency hopping spread spectrum 142 

8.3.3 WLAN industry standard 142 

8.4 IEEE 802.11 WLAN Architecture 143 

8.4.1 IEEE 802.11a and IEEE 802.11b 145 

8.5 Bluetooth 146 

8.5.1 Bluetooth architecture 147 

8.5.2 Bluetooth applications 152 

8.5.3 Bluetooth devices 154 

8.6 Summary 157 

Problems to Chapter 8 158 

9 Routing Protocols in Mobile and Wireless Networks 163 

9.1 Table-driven Routing Protocols 164 

9.1.1 Destination-sequenced distance-vector routing 164 

9.1.2 The wireless routing protocol 166 

9.1.3 Global state routing 166 

9.1.4 Fisheye state routing 167 

9.1.5 Hierarchical state routing 167 

9.1.6 Zone-based hierarchical link state routing protocol 168 

9.1.7 Cluster-head gateway switch routing protocol 168 

9.2 On-demand Routing Protocols 169 

9.2.1 Temporally ordered routing algorithm 169 

9.2.2 Dynamic source routing protocol 171 

9.2.3 Cluster-based routing protocol 173 

9.2.4 Ad hoc on-denrand distance-vector routing 174 

9.2.5 Signal stability-based adaptive routing 175 

9.2.6 Associativity-based routing 176 

9.2.7 Optimized link state routing 177 

9.2.8 Zone routing protocol 177 

9.2.9 Virtual subnets protocol 178 

9.3 Summary 179 

Problems to Chapter 9 179 

10 Handoff in Mobile and Wireless Networks 181 

10.1 Signaling Handoff Protocol in WATM Networks 184 

10.2 Crossover Switch Discovery 185 






CONTENTS 



10.3 Rerouting Methods 187 

10.4 Optimized COS Discovery through Connection Grouping 188 

10.5 Schedule-assisted Handoffs 189 

10.6 Handoff in Low Earth Orbit (LEO) Satellite Networks 189 

10.7 Predictive Reservation Policy 190 

10.8 Chaining Approaches 191 

10.8.1 Hop-limited handoff scheme 191 

10.8.2 Chaining followed by make-break 191 

10.9 Analysis of Chaining Handoff Approaches 193 

10.10 Summary 194 

Problems to Chapter 10 194 

11 Signaling Traffic in Wireless ATM Networks 197 

11.1 A Model of WATM Network 1 97 

11.2 Chain Routing Algorithm 199 

11.3 Implementation of the Handoff Scheme 202 

1 1 .4 Analysis of the Chain Routing Algorithm 203 

1 1 .4. 1 Comparison of chain routing algorithm with hop-limited 

method 203 

1 1 .4.2 Analysis of the signaling traffic cost 205 

11.4.3 Handoff latency 207 

11.5 Summary 210 

Problems to Chapter 11 210 

12 Two-phase Combined QoS-based Handoff Scheme 213 

12.1 Wireless ATM Architecture 214 

12.2 Mobility Support in Wireless ATM 217 

12.3 Comparison of Rerouting Schemes 222 

12.4 Maintaining the Cell Sequence During Path Optimization 224 

12.5 Combined QoS-based Path Optimization Scheme 227 

12.6 Summary 230 

Problems to Chapter 12 230 

References 233 



Index 



239 





Preface 



Mobile telecommunications emerged as a technological marvel allowing for access to 
personal and other services, devices, computation and communication, in any place and 
at any time through effortless plug and play. This brilliant idea became possible as the 
result of new technologies developed in the areas of computers and communications that 
were made available and accessible to the user. 

This book describes the recent advances in mobile telecommunications and their pro- 
tocols. Wireless technologies that expanded to a wide spectrum and short-range access 
allow a large number of customers to use the frequency spectrum when they need it. 
Devices are used to communicate with the expanded network. Software systems evolved 
to include mobile agents that carry service information that is compact enough to be 
implemented in the end user devices. 

The area of mobile telecommunications has been growing rapidly as new technologies 
emerge. Mobile users are demanding fast and efficient connections that support data 
applications. Extending wireless access to the applications requires creating mobile agents, 
systems, and platforms to implement service configuration. Wireless Local Area Networks 
(LANs) supporting a growing number of users and applications require wideband wireless 
local access, wireless protocols, and virtual LANs. Wireless applications require protocols 
and architecture supporting these applications. Wireless connection has to be provided by 
the networks and protocols. Mobile networks must function efficiently by using their 
protocols, performing routing and handoff for mobile users. 

This book focuses on the newest technology for mobile telecommunications support- 
ing data applications. The book provides a real application-oriented approach to solving 
mobile communications and networking problems. The book addresses a broad range of 
topics from mobile agents and wireless LANs to wireless application protocols, wireless 
architecture, and mobile networks. 

This book proposes a comprehensive design for mobile telecommunications including 
mobile agents, access networks, application protocols, architecture, routing, and handoff. 
For mobile users and data applications, these are new networking and communications 
solutions, particularly for the LAN environment. The book describes the aspects of mobile 
telecommunications for applications, networking, and transmission. Additionally, it intro- 
duces and analyzes architecture and design issues in mobile communications and networks. 

The book is organized into 12 chapters. The first seven chapters describe applications, 
their protocols and mobile and wireless network support for them. Chapters 8 through 
12 describe architecture of mobile and wireless networks, their protocols, and quality-of- 
service (QoS) issues. 
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PREFACE 



The goal of this book is to explain how to support modem mobile telecommunications, 
which evolve toward value-added, on-demand services, in which the need for communica- 
tion becomes frequent and ongoing, and the nature of the communication becomes more 
complex. Mobile agents are used to enable on-demand provision of customized services. 
Examples of mobile agent-based service implementation, middleware, and configuration 
are introduced. 

Mobile applications are supported by wireless LANs. Virtual LANs provide support 
for workgroups that share the same servers and other resources over the network. 

Orthogonal Frequency Division Multiplex (OFDM) allows individual channels to main- 
tain their orthogonality, or distance, to adjacent channels. This technique allows data 
symbols to be reliably extracted and multiple subchannels to overlap in the frequency 
domain for increased spectral efficiency. The IEEE 802.11 standards group chose OFDM 
modulation for wireless LANs operating at bit rates up to 54 Mbs -1 at 5GFlz. 

Wideband Code Division Multiple Access (WCDMA) uses 5-MHz channels and sup- 
ports circuit and packet data access at 384 kb $ -1 nominal data rates for macrocellular 
wireless access. WCDMA provides simultaneous voice and data services. WCDMA is 
the radio interface technology for Universal Mobile Telecommunications System (UMTS) 
networks. 

Mobile applications and wireless LANs use wireless protocols. A Media Access Control 
(MAC) protocol for a wireless LAN provides two types of data-transfer Service Access 
Points (SAP): network and native. The network SAP offers an access to legacy network 
protocols [e.g., IP (Internet Protocol)]. The native SAP provides an extended service 
interface that may be used by custom network protocols or user applications capable of 
fully exploiting the protocol-specific QoS parameters within the service area. 

Limitations of power, available spectrum, and mobility cause wireless data networks to 
have less bandwidth and more latency than traditional networks, as well as less connection 
stability than other network technologies, and less predictable availability. 

Mobile devices have a unique set of features that must be exposed into the World 
Wide Web (WWW) in order to enable the creation of advanced telephony services such 
as location-based services, intelligent network functionality, including integration into the 
voice network, and voice/data integration. 

The Wireless Application Protocol (WAP) architecture provides a scalable and exten- 
sible environment for application development for mobile communication devices. The 
WAP protocol stack has a layered design, and each layer is accessible by the layers above 
and by other services and applications. The WAP layered architecture enables other ser- 
vices and applications to use the features of the WAP stack through a set of well-defined 
interfaces. External applications can access the session, transaction, security, and transport 
layers directly. 

The network architecture supporting wireless applications includes Wireless Appli- 
cations Environment (WAE), Wireless Telephony Application (WTA), and WAP Push 
framework. The WAE architecture is designed to support mobile terminals and network 
applications using different languages and character sets. 

WTA is an application framework for telephony services. The WTA user agent has the 
capabilities for interfacing with mobile network services available to a mobile telephony 
device, that is, setting up and receiving phone calls. 
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The WAP Push framework introduces a means within the WAP effort to transmit 
information to a device without a previous user action. In the client/server model, a client 
requests a service or information from a server, which transmits information to the client. 
In this pull technology, the client pulls information from the server. 

Extensible Markup Language (XML) is an application profile or restricted form of the 
Standard Generalized Markup Language (SGML). XML describes a class of data objects 
called XML documents and partially describes the behavior of computer programs that 
process them. Resource Description Lramework (RDL) can be used to create a general, 
yet extensible, framework for describing user preferences and device capabilities. This 
information can be provided by the user to servers and content providers. The servers can 
use this information describing the user’s preferences to customize the service or content 
provided. 

A Composite Capability/Preference Profile (CC/PP) is a collection of the capabilities 
and preferences associated with the user and the agents used by the user to access the 
World Wide Web (WWW). These user agents include the hardware platform, system 
software, and applications used by the user. 

In a wireless LAN, the connection between the client and the user exists through the use 
of a wireless medium such as Radio Lrequency (RL) or Infrared (IR) communications. 
The wireless connection is most usually accomplished by the user having a handheld 
terminal or a laptop computer that has an RL interface card installed inside the terminal 
or through the PC (personal computer) card slot of the laptop. The client connection from 
the wired LAN to the user is made through an Access Point (AP) that can support multiple 
users simultaneously. The AP can reside at any node on the wired network and performs 
as a gateway for wireless users’ data to be routed onto the wired network. 

A wireless LAN is capable of operating at speeds in the range of 1 or 2, or 11 Mbps 
depending on the actual system. These speeds are supported by the standard for wireless 
LAN networks defined by the international body, the IEEE. 

The network communications use a part of the radio spectrum that is designated as 
license-free. In this band, of 2.4 to 2.5 GHz, the users can operate without a license when 
they use equipment that has been approved for use in this license-free band. The 2.4-GHz 
band has been designated as license-free by the International Telecommunications Union 
(ITU) and is available for use, license-free in most countries in the world. 

The ability to build a dynamically scalable network is critical to the viability of a 
wireless LAN as it will inevitably be used in this mode. The interference rejection of 
each node will be the limiting factor to the expandability of the network and its user 
density in a given environment. 

In ad hoc networks, all nodes are mobile and can be connected dynamically in an 
arbitrary manner. All nodes of these networks behave as routers and take part in discovery 
and maintenance of routes to other nodes in the network. 

An ad hoc network is a collection of mobile nodes forming a temporary network 
without the aid of any centralized administration or standard support services available 
in conventional networks. 

Ad hoc networks must deal with frequent changes in topology. Mobile nodes change 
their network location and link status on a regular basis. New nodes may unexpectedly 
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join the network or existing nodes may leave or be turned off. Ad hoc routing protocols 
must minimize the time required to converge after the topology changes. 

The ad hoc routing protocols can be divided into two classes: table-driven and on- 
demand routing on the basis of when and how the routes are discovered. In table-driven 
routing protocols, consistent and up-to-date routing information to all nodes is maintained 
at each node, whereas in on-demand routing, the routes are created only when desired by 
the source host. 

When the mobile end user moves from one AP to another AP, a handoff is required. 
When the handoff occurs, the current QoS may not be supported by the new data path. In 
this case, a negotiation is required to set up new QoS. Since a mobile user may be in the 
access range of several APs, it will select the AP that provides the best QoS. During the 
handoff, an old path is released and then a new path is established. Connection rerouting 
schemes must exhibit low handoff latency, maintain efficient routes, and limit disruption 
to continuous media traffic while minimizing reroute updates to the network switches 
and nodes. 

Basically, there are three connection rerouting approaches: full connection establish- 
ment, partial connection re-establishment, and multicast connection re-establishment. 

In the wireless Asynchronous Transfer Mode (ATM) network, a radio access layer 
provides high-bandwidth wireless transmission with appropriate medium access control 
and data link control. A mobile ATM network provides base stations (access points) 
with appropriate support of mobility-related functions, such as handoff and location 
management. 

QoS-based rerouting algorithm is designed for the two-phase interswitch handoff scheme 
for wireless ATM networks. Path extension is used for each inter-switch handoff, and path 
optimization is invoked when the handoff path exceeds the delay constraint or maximum 
path extension hops constraint. The path optimization schemes include combined QoS- 
based, delay-based, and hop-based path rerouting schemes. 

The content of the book is organized into 12 chapters as follows: 

Chapter 1 introduces mobile agents and presents platforms and systems to imple- 
ment agent-based services in the network. Chapter 2 describes mobile agent-based service 
implementation. Mobile agent-based middleware and service configuration are introduced. 
Mobile agent implementation is discussed. 

Chapter 3 describes wireless LANs, introduces virtual LANs, and presents wideband 
wireless local access. Chapter 4 describes wireless protocols. 

Protocols for wireless applications are studied in Chapter 5. Wireless applications and 
devices are discussed and wireless application protocol is introduced. Network architecture 
supporting wireless applications is presented in Chapter 6. Extensible markup language, 
resource description framework, and composite capability/preference profile are described 
in Chapter 7. 

Architecture of wireless LANs is studied in Chapter 8. The protocols supporting mobile 
communications, IEEE 802.11 and Bluetooth, are described. 

Routing protocols in mobile and wireless networks are presented in Chapter 9. Handoff 
in mobile networks is described in Chapter 10. Signaling traffic in wireless networks is 
studied in Chapter 11. Chapter 12 presents a two-phase combined handoff scheme in 
wireless networks. 
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1 

Mobile agent platforms 

and systems 



Advanced service provisioning allows for rapid, cost-effective service deployment. Mod- 
ern mobile telecommunications evolve towards value-added, on-demand services in which 
the need for communication becomes frequent and ongoing, and the nature of the commu- 
nication becomes more complex. The services of the future will be available ‘a la carte’, 
allowing subscribers to receive content and applications when they want it. 

Introducing Mobile Agents (MAs) within the network devices, Mobile Stations (MSs), 
and Mobile Switching Centers (MSCs) provides the necessary flexibility into the network 
and enhanced service delivery. MAs enable on-demand provision of customized services 
via dynamic agent downloading from the provider system to the customer system or 
directly to the network resources. MAs have the capability to migrate between networks, 
to customize for the network, and to decentralize service control and management software 
by bringing control and managements agents as close as possible to the resources. 

MAs can be used in mobile networks to support advanced service provisioning, as well 
as for personal communication, for mobility, and to support Virtual Home Environment 
(VHE). The VHE agent enables individually subscribed and customized services to follow 
their associated users to wherever they roam. 



1.1 MOBILE AGENT PLATFORMS 

Mobile Agent Technology (MAT) uses interworking between Mobile Agent Platforms 
(MAPs). Several MAPs are based on Java. These platforms are Grasshopper, Aglets, 
Concordia, Voyager, and Odyssey. 

Each MAP has a class library that allows the user to develop agents and applications. 
The core abstractions are common to most platforms since they are inherent in the MA 
paradigm. These abstractions include agents, hosts, entry points, and proxies. 
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MOBILE AGENT PLATFORMS AND SYSTEMS 



• Agents: In each platform, a base class provides the fundamental agent capability. In 
some platforms this base class is used for all agents (static and mobile) while in others 
there are two separate classes. 

• Hosts : The terms hosts, environments, agencies, contexts, servers, and AgentPlaces are 
used to refer to the components of the framework that must be installed at a computer 
node and that provide the necessary runtime environment for the agents to execute. 

• Entry points: The agents have to save the necessary state information to member 
variables, allowing the entry point method to proceed depending on the state of the 
computation. Platforms may have one or multiple entry points. 

• Proxies : The proxy is a representative that an MA leaves when migrating from a node, 
and it can be used to forward messages or method invocations to an MA in a location- 
independent manner. Platforms may implement proxies in different ways. A significant 
difference is whether the arbitrary methods of an agent can be called remotely through 
the proxy. Platforms that support this functionality provide a utility that parses a MA's 
class and creates a corresponding proxy. In platforms where arbitrary Remote Method 
Invocation (RMI) through a proxy is not supported, the proxy object provides only a 
uniform, generic method to send messages, and therefore no proxy-generation utility 
is required. 

1.1.1 Grasshopper 

The Grasshopper platform consists of a number of agencies (hosts) and a Region Registry 
(a network-wide database of host and agent information) remotely connected via an Object 
Request Broker (ORB). Agencies represent the runtime environments for MAs. Several 
agencies can be grouped into one region represented by a region registry. 

Remote interactions between the components of the Distributed Agent Environment 
(DAE) are performed via an ORB. The Grasshopper’s Communication Service is a part of 
each agency and region registry. The Grasshopper supports the following protocols: plain 
sockets (with or without Secure Socket Layer, SSL), Common Object Request Broker 
Architecture (CORBA) Internet Inter - ORB Protocol (HOP), and RMI - with or without 
SSL. Support for more protocols can be integrated into the communication service. 

The Grasshopper platform conforms to the Object Management Group’s (OMG) Mobile 
Agent System Interoperability Facility (MASIF) standard. 



1.1.2 Aglets 

Aglets (Agent applets) were developed by the IBM Tokyo Research Laboratory. The 
Aglets class library provides an Application Programming Interface (API) that facilitates 
the encoding of complex agent behavior. Particularly, the way the behavior of the base 
Aglet class is extended resembles the way Web applets are programmed. Aglets can 
cooperate with web browsers and Java applets. 

The communication API used by Aglets is derived from MASIF standard. The default 
implementation of the API is the Agent Transfer Protocol (ATP). ATP is an application 
level protocol based on TCP and modeled on the Hypertext Transfer Protocol (HTTP) 
for transmitting messages and MAs between the networked computers in which the hosts 
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reside. The core Aglet runtime is independent of the transport protocol and accesses ATP 
through a well-defined interface. Aglets use an interface, derived from MASIF standard, 
for the internal communication between the runtime core and the communication system, 
but do not export this interface as an external CORBA interface. The latest version of 
Aglets supports ATP and RMI. A CORBA IlOP-based transport layer will be provided 
in the future release of Aglets. 



1.1.3 Concordia 

Concordia was developed by Mitsubishi Electric Information Technology Center, USA. 
The main component of the Concordia system is the Concordia server that provides for 
the necessary runtime support. The server consists of components integrated to create 
MA framework. 

Concordia uses TCP/IP communication services. The communication among agents 
and their migration employs Java’s RMI, where standard sockets are replaced by secure 
sockets (SSL). 



1.1.4 Voyager 

Voyager developed by ObjectSpace is a Java-based MA system. Voyager relies exclu- 
sively on the services of its supporting ORB. The core functionality of an ORB is to 
facilitate interobject communication by shuttling messages to and from remote objects 
and instantiating persistent distributed objects. Voyager’s ORB can facilitate only Java 
objects, and this is not an OMG-compatible ORB. 

Features supported by the Voyager’s ORB include migration of both agents and arbi- 
trary Java object (a feature that does not exist in other MAPs), the ability to remote-enable 
(instantiate) a class, remote execution of static methods, multicast messaging, synchronous 
messages, and time-dependent garbage collection. ObjectSpace has implemented hooks 
in the Voyager to support interworking with other ORBs. 



1.1.5 Odyssey 

Odyssey is a Java-based MAP implemented by General Magic. Odyssey uses Java’s RMI 
for communication between Agents. The transport mechanism used for Agent migration 
can be CORBA IIOP, Distributed Component Object Model (DCOM), or RMI. Agents 
cannot call remotely the methods of other Agents but can engage with them in a meeting. 



1.2 MULTIAGENT SYSTEMS 

Agent-based technology offers a solution to the problem of designing efficient and flexible 
network management strategies. The OMG has produced the MASIF, which focuses on 
mobile agent (object) technology, in particular, allowing for the transfer of agents code 
and state between heterogeneous agent platforms. 
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MOBILE AGENT PLATFORMS AND SYSTEMS 



The Intelligent Network (IN) was developed to introduce, control, and manage services 
rapidly, cost effectively, and in a manner not dependent on equipment and software from 
particular equipment manufactures. The architecture of an IN consists of the following 
node types: Service Switching Points (SSPs), Service Control Points (SCPs), Service 
Data Points (SDPs), and Intelligent Peripherals (IP). These nodes communicate with each 
other by using a Signaling System No. 7 (SS7) network. SSPs facilitate end user access 
to services by using trigger points for detection of service access codes. SCPs form the 
core of the architecture; they receive service requests from SSPs and execute the service 
logic. SCPs are assisted by SDPs, which store service/customer related data, and by IPs, 
which provide services for interaction with end users (e.g., automated announcements or 
data collection). 

IN overloads occur when the load offered to one or more network resources (e.g., 
SCP processors) exceeds the resource’s maximum capacity. Because of the central role 
played by the SCP, the overall goal of most IN load control mechanisms is to protect SCP 
processors from overload. The goal is to provide customers with high service availability 
and acceptable network response times, even during periods of high network loading. 
Load control mechanisms are designed to be 

• efficient - keeping SCP utilization high at all times; 

• scalable - suited to all networks, regardless of their size and topology; 

• responsive - reacting quickly to changes in the network or offered traffic levels; 

• fair - distributing system capacity among network users and service providers in a 
manner deemed fair by the network operator; 

• stable - avoiding fluctuations or oscillations in resources utilization; 

• simple - in terms of ease of implementation. 

The majority of IN load control mechanisms are node-based, focusing on protect- 
ing individual nodes in the network (typically SCPs) from overload. Jennings et al. 
argue that node-based mechanisms cannot alone guarantee that desired Quality of Ser- 
vice (QoS) levels are consistently achieved. The following observations support this 
viewpoint: 

• Most currently deployed node-based mechanisms were designed for standard telephony 
traffic patterns. Present and future INs support a large number of heterogeneous services, 
each exhibiting changing traffic characteristics that cannot be effectively controlled by 
using node-based techniques. 

• Existing node-based overload protection mechanisms serve to protect individual nodes 
only and may cause the propagation of traffic congestion, resulting in adverse effects 
on the service completion rates of the network as a whole. 

• Typically node-based mechanisms do not interact effectively with the protection mech- 
anisms that are incorporated into the signaling networks that carry information between 
the nodes in a network. 

• Node-based controls typically focus on SCP protection only. 

• Telecommunications equipment manufactures implement node-based mechanisms on a 
proprietary basis. This can lead to difficulties in effectively controlling traffic in INs 
that contain heterogeneous types of equipment. 
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While flexible and adaptable network-based load control mechanisms can be imple- 
mented by using standard software engineering techniques, Jennings et cil. argue that there 
are many advantages of adopting an agent-based approach: 

• Methodology: The agent paradigm encourages an information-centered approach to 
application development; thus it provides a useful methodology for the development 
of control mechanisms that require manipulation of large amounts of data collected 
throughout the network. 

• Agent communication languages: Advanced communication languages allow agents 
to negotiate in advance the semantics of future communications. This is not present 
in traditional communications protocols and can be used in mechanisms that adapt to 
dynamic network environments in which, for instance, traffic patterns change as a result 
of the introduction or withdrawal of services. 

• Adaptivity: The agents adaptive behavior allows them to learn about the normal state 
of the network and better-judge their choice of future actions. 

• Openness : Agents can exchange data and apply it in different ways to achieve a common 
goal. This means that equipment manufacturers can develop load control agents for their 
own equipment, but these agents can still communicate with agents residing in other 
equipment types. 

• Scalability: The agent approach allows for increased scalability to larger networks. For 
instance, an agent associated with a recently introduced piece of equipment can easily 
incorporate itself into the agent community and learn from the other agents the range 
of parameters that it should use for its load control algorithm. 

• Robustness: Agents typically communicate asynchronously with each other and thus 
are not dependent on the prompt delivery of interagent messages. The ability to act 
even during interrupted communications (e.g., due to overload or network failures) is 
a desirable attribute of a load control mechanism. 

1.2.1 Agent-based load control strategies 

The goal of the agent-based load control strategies is to allocate resources to the arriving 
user service requests in an optimal way. There are three classes of agents that carry out 
the tasks necessary to allocate IN resources in this optimal way: 

• QUANTIFIER agents that monitor and predict the load and performance of SCP proces- 
sors (and possibly other IN resources) and report this information to the other agents; 

• DISTRIBUTOR agents that maintain an overview of the load and resource status in the 
entire network and can play a controlling and supervisory role in resource allocation; 

• ALLOCATOR agents that are associated with SSPs. They form a view of the load 
situation in the network and the possibility of resource overload, based on their own 
predictive algorithms and information received from the other agents. If these agents 
perceive a danger of overload of resources, they throttle service requests on a prior- 
ity basis. 

The allocation of the processing capacity of a number of SCPs between requests for a 
number of IN service types can be controlled by strategies using the agents: QUANTI- 
FIERS, DISTRIBUTORS, and ALLOCATORS. A simple network containing SSPs and 
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Figure 1.1 Agent-based load control strategy. 



SCPs, each supporting all service types, is shown in Figure 1.1 and is used to describe 
agent-based load control strategies. 

Computational markets, as applied to resource allocation problems, are generally imple- 
mentations of the General Equilibrium Theory, developed in the held of microeconomics, 
whereby agents in the market set prices and create bids for resources, on the basis of 
demand-and-supply functions. Once equilibrium has been computed from the bids of all 
the agents, the resources are allocated in accordance with the bids and the equilibrium 
prices. The search for the market equilibrium can be implemented so that the customer 
and producer submit bids to an auctioneer. From these bids, the auctioneer updates its 
information and requests new bids in an iterative fashion. Once the market equilibrium 
has been found, the allocation of goods is performed in accordance with the bids and 
market prices. 

In the market strategy, load control is carried out by means of tokens, which are 
sold by MB-QUANTIFIER agents (MB indicates that the agent implements part of a 
market-based strategy) of providers (SCP) and bought by MB-ALLOCATOR agents of 
customers (SSP). The amount of tokens sold by an SCP controls the load offered to it, 
and the amount of tokens bought by an SSP determines how many IN service requests 
it can accept. Trading of tokens in an auction is carried out so that the common benefit 
is maximized. 

All SSPs contain a number of pools and tokens, one for each SCP and service class 
pairing. Each time an SSP feeds an SCP with a service request, one token is removed from 
the relevant pool. An empty pool indicates that the associated SCP cannot accept more 
requests of that type from the SSP. Tokens are periodically assigned to pools by an MB- 
DISTRIBUTOR, which uses an auction algorithm to calculate token allocations. Auctions 
are centrally implemented by an MB-DISTRIBUTOR using bids received in the form of 
messages every interval from all the MB-ALLOCATORS and MB-QUANTIFIERS in 
the network. 
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MB-QUANTIFIER bids consist of the unclaimed processing capability for the coming 
interval and the processing requirements for each service class. MB-ALLOCATOR bids 
consist of the number of expected IN service requests over the next interval for each 
service class. These values are set to the numbers that arrived in the previous interval as 
they are assumed to be reasonably accurate estimates. 

The objective of the auction process is to maximize expected network profit over 
the next interval by maximizing the increase in expected marginal utility, measured as 
marginal gain over cost, for every token issued. The expected marginal gain associ- 
ated with allocating an additional token to an MB-ALLOCATOR is defined as the profit 
associated with consuming it times the probability that it will be consumed over the 
auction interval. The expected marginal cost associated with issuing a token from an 
MB-QUANTIFIER is defined as the ratio between the processing time consumed and the 
remaining processing time. On the basis of these values, the MB-DISTRIBUTOR imple- 
ments a maximization algorithm that is iterated to allocate all the available tokens. Tokens 
are typically allocated to MB-ALLOCATORS with higher bids (i.e., those that expect 
greater number of requests for service sessions that result in high profits) in preference 
to those with lower bids. 

The operation of the auction algorithm in which there is only one service class sup- 
ported by the network is shown in Figure 1 .2. In the first step, that is. Bid Submission, MB- 
QUANTIFIERS and MB-ALLOCATORS submit their bids to the MB-DISTRIBUTOR, 
which then executes the second step, that is, Auction Process. In this figure, dark circles 
represent tokens, whereas light circles represent token requests; the auction algorithm 
assigns tokens to token requests. Once the auction is completed, in the third step the 




Figure 1.2 Auction algorithm with one service class in cooperative market strategy. 
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values of token assignments are reported to the MB -ALLOCATORS, which use them to 
admit service requests in the next time period. 

The result of the auction process is that tokens are allocated to balance the arriving 
traffic load across all SCPs, subject to maximizing the overall network profit. 

The following load control strategy is based on Ant Colony Optimization, which is 
the application of approaches based on the behavior of real ant colonies to optimization 
problems. The operation of ant-based IN load control strategy is shown in Figure 1.3. 

At intervals of length T, a mobile agent AB-ANT, where AB indicates ant-based 
strategy, is generated for every service type at every SSP in the network and sent to a 
selected SCP. Each SSP maintains pheromone tables for each service type, which contain 
entries for all the SCPs in the network. These entries are the normalized probabilities, P, 
for choosing SCP, as the destination for an AB-ANT. The destination SCP of an AB- 
ANT is selected using the information in the pheromone table following either the normal 
scheme or the exploration scheme. The scheme used is selected at random, but with the 
probability of using the normal scheme much higher than the exploration scheme. 

In the normal scheme, the SCP is selected randomly, the probability of picking SCP, 
being the probability P, indicated in the pheromone table. In the exploration scheme, the 
SCP is also selected randomly, and the probabilities of selecting all the SCPs are equal. 
The puipose of the exploration scheme is to introduce an element of noise into the system 
so that more performant SCPs can be found. 

AB-ANTS travel to the designated SCP, where they interact with the local AB- 
QUANTIFIER agent and then return to their originating SSP. They also keep track of 
the time they have spent traversing the network. AB-ANTS arriving at the SCP request 
information from the AB-QUANTIFIER on the currently expected average processing 




Figure 1.3 Ant-based IN load control strategy. 
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times for the service type of interest. Processing times reported are the processing time 
for the initial message of the service session and the sum of the processing times for all 
other messages. The separation between the processing times for the initial and subse- 
quent messages is used to highlight the importance of the time spent processing the initial 
message, by which time the service user would not have received any response from the 
network. Reported processing times include those incurred in accessing information from 
databases, which may be held in SDPs in other parts of the network. 

Upon return to the SSP, the AB-ANT passes its gathered information to the AB- 
ALLOCATOR, which then updates the pheromone table entries for its service type, using 
the following formula. 

p = p i + A p 
1 1 + A p 

where i indicates the visited SCP, and P, is the probability of choosing SCP,. The prob- 
ability Pj of choosing SCP, is 



Pj = J - — , 

1 + A p 



j e j*i 



with 



abed 
A p — 1 1 1 be 

t i h tj, U 



where a,b,c,d, and e are constants; i\ is time-elapsed traveling SSP — »• SCP; U is 
expected mean SCP processing time for initial message; r 3 is expected mean SCP pro- 
cessing time for subsequent messages; f 4 is time-elapsed traveling SCP — »• SSP. 

The values of a, b, c, and d represent the relative importance the AB-ALLOCATOR 
gives to each of the four measurements. Requests for service are routed to the SCP that has 
the current highest priority value in the service’s pheromone table. Figure 1.3 illustrates 
that in normal load conditions the operation of the strategy will mean that SCPs with 
closer proximity to a source are more likely to be chosen as the destination for service 
requests, the reason being that the delays AB-ANTS experience in traveling to and from 
them are lower than for other SCPs. 



1.3 SUMMARY 

Each MAP has a class library that allows the user to develop agents and applications. 
The core abstractions are common to most platforms since they are inherent in the MA 
paradigm. These abstractions include agents, hosts, entry points, and proxies. 

Agent-based technology offers a solution to the problem of designing efficient and 
flexible network management strategies. The OMG has produced the MASIF standard, 
which focuses on MA (object) technology, in particular, allowing for the transfer of agents 
code and state between heterogeneous agent platforms. 

Load control mechanisms are designed to be efficient, scalable, responsive, fair, stable, 
and simple. 
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The majority of IN load control mechanisms are node-based, focusing on protecting 
individual nodes in the network (typically SCPs) from overload. Node-based mechanisms 
cannot alone guarantee that desired QoS levels are consistently achieved. 

Flexible and adaptable network-based load control mechanisms can be implemented by 
using standard software engineering techniques. There are many advantages of adopting 
an agent-based approach, which include methodology, agent communication languages, 
adaptivity, openness, scalability, and robustness. 



PROBLEMS TO CHAPTER 1 

Mobile agent platforms and systems 

Learning objectives 

After completing this chapter, you are able to 

• demonstrate an understanding of MAs; 

• discuss what is meant by MA platforms; 

• explain what agent-based technology is; 

• demonstrate an improvement to network load control mechanisms; 

• explain what an intelligent network is; 

• discuss the node-based and agent-based approach. 



Practice problems 

1.1: What are the core abstractions common to most platforms in the mobile agent 
paradigm? 

1.2: What are the requirements for the load control mechanisms? 

1.3: What are the advantages of using an agent-based approach to load control? 

Practice problem solutions 

1.1: The core abstractions common to most platforms in the mobile agent paradigm 
include agents, hosts, entry points, and proxies. 

1.2: Load control mechanisms are designed to be efficient, scalable, responsive, fair, 
stable, and simple. 

1.3: The advantages of adopting an agent-based approach to load control include 
methodology, agent communication languages, adaptivity, openness, scalability, and 
robustness. 
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2 

Mobile agent-based service 
implementation, middleware, 

and configuration 



There are two agents groups: Intelligent Agents and Mobile Agents (MAs). Intelligent 
Agents have the ability to learn and react. MAs can migrate between different hosts, 
execute certain tasks, and collaborate with other agents. 

In the Intelligent Network (IN) architecture, the control of the network resources is 
performed by the signaling plane, whereas the service creation, deployment, and provi- 
sioning is performed by the service plane. This separation allows introduction of new 
services and service features without changing the basic functionality of the network for 
the establishment and the release of resources such as calls and connections. 

Traffic in the signaling network is reduced by moving services closer to the cus- 
tomers, and the messages related to service control are handled locally. The overhead of 
downloading service programs is done off-line and does not impact signaling performance. 

MAs enable both temporal distribution (i.e., distribution over time) and spatial distri- 
bution (i.e., distribution over different network nodes) of service logic. 

MAs can be implemented in Java programming language. Additional features and 
mechanisms supported and envisioned in Jini programming language allow for imple- 
mentation of mobile devices in practical systems. 



2.1 AGENT-BASED SERVICE IMPLEMENTATION 

Distributed Object Technology (DOT) provides a Distributed Processing Environment 
(DPE) to enable designers to create object-oriented distributed applications, which are not 
necessarily aware of the physical layout of the underlying network structure hidden by 
platform services. DOT-based specifications of DPEs, like CORBA 2.0, have been adopted 
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by the Telecommunications Information Networking Architecture (TINA) Consortium as 
the basis for the distributed architecture. 

Mobile Agent Technology (MAT) uses the capabilities provided by machine-indepen- 
dent, interpreted languages like Java to deploy a framework in which applications can 
roam between network nodes maintaining their execution status. MAT platforms are often 
based on a CORBA DPE layer that allows distributed applications to dynamically recon- 
figure their layout according, for instance, to processing needs. This way certain MAs may 
have a CORBA interface enabling them to exploit the facilities offered by the distributed 
objects communication infrastructure. 

This framework provides service designers with additional flexibility by using CORBA 
object location and object interfacing facilities, and by using code migration capabilities 
to dynamically upgrade network nodes with new applications. 

The application of DOT and MAT to the IN architecture provides benefits to the service 
provisioning process as shown in Figure 2.1, with maintaining the basic principle of IN 
related to call and service separation. 

The introduction of DOT and MAT at the service design and deployment level allows 
for reusability for easy and rapid deployment of services, extensibility towards new and 
updated services, and flexibility of service design. The adoption of DOT and MAT within 
the Service Switching Points (SSPs) allows for services distribution among the switches 
with faster handling of service requests, more reliable service execution, and network 
scalability. 

In the IN architecture, the control of the network resources is performed by the signaling 
plane, whereas the service creation, deployment, and provisioning is performed by the 
service plane. This separation allows introduction of new services and service features 



Intrinsic 
bottlenecks in 
traditional IN 
can lead to poor 
performances 



New technologies 
for network 
unaware of 
distributed 
applications 



Adaptive broadband service provisioning architecture 
Open switching platforms able to accommodate mobile code 



High expenses 
in switching 
design and 
maintenance 



Mobile code 
supports 
dynamically 
reconfigurable 
network structures 



Figure 2.1 Application of DOT and MAT to the IN. 
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without changing the basic functionality of the network for the establishment and the 
release of resources such as calls and connections. 

In the IN architecture, the intelligence is kept inside the core network that reduces 
the need to update the equipment of the Access Network (AN) representing the most 
widespread and expensive portion of the overall network. The IN architecture shown in 
Figure 2.2 comprises functional entities mapped into physical elements. 

The communication between network entities is done through Signaling System No. 7 
(SS7). The Intelligent Network Application Protocol (INAP) also uses SS7 for the IN 
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Figure 2.2 Deployment of functional entities to physical entities in the IN. 





14 



MOBILE AGENT-BASED SERVICE IMPLEMENTATION, MIDDLEWARE, AND CONFIGURATION 




Figure 2.3 Introduction of DOT and MAT in the IN for service design, deployment, and 

maintenance. 



messages. IN architecture can support third-generation mobile systems and has the capacity 
of the third-party call setup between IN and the Internet. 

Figure 2.3 illustrates how DOT and MAT are introduced at the service design, deploy- 
ment, and maintenance level. Services are designed as Java-based MAs in Service Creation 
Environments (SCEs) and then transferred to the Service Control Points (SCPs) by using 
capabilities provided by Mobile Agent Platforms (MAPs). In this architecture, SCPs 
contain CORBA and MAT in their design. Service providers benefit from a flexible 
service-provisioning environment by adopting object-oriented techniques for software 
design and by using MAT facilities to apply immediate and sophisticated policies for 
release distribution, update, and maintenance. Service Management System (SMS) stores 
and distributes services and manages the running service instances. 

MAPs are introduced in the switching nodes. CORBA method invocations are used 
between SSPs and SCPs as an alternative to INAP as shown in Figure 2.4. The service 
logic (arrow 1) can be duplicated and distributed to the SCPs (arrows 2, 3, n), and directly 
to the SSPs. In this case, SS7 is only used for communication between SSPs. 

This architecture with service distribution to the switches allows for faster handling of 
service requests, higher reliability in handing the services, scalability, and reduction of 
traffic in the signaling network. 

Service requests are handled faster by using an agent in the switch that causes call 
handling, which usually does not require the establishment of a transaction with an SCP 
and the consequent exchange of messages in the network. Therefore, no complex protocol 
stacks are needed below the application part. Instead, communication between internal 
switch processes occurs. 
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Figure 2.4 Introduction of MAPs in the IN switches. 



The impact of network faults on the behavior of service is reduced since the network is 
accessed mainly to download the service logic. Network errors can occur during download- 
ing Service Location Protocols (SLPs) (i.e., agent migration) or during a Remote Method 
Invocation (RMI) (through CORBA infrastructure). These situations can be handled by 
using persistent mechanisms. Most MATs offer persistent agent facilities and, for CORBA 
objects, the Persistent Object Service (POS) can be used. This way service performance 
degradation is reduced. 

The problem of having centralized points is solved by distributing the service code 
across the network, which has a larger number of switches than SCPs. Dynamic SLP/SDT 
(Service Description Table) distribution allows IN services to be spread across the network 
to satisfy higher demand for those services. The distribution is performed dynamically 
when it is needed. In a distributed IN, the SLPs of the first IN calls are downloaded from 
the SMS to the SCP and then executed in the SCP. When the capacity of IN calls in 
SCP is exceeded, the SLPs are downloaded to the SSP, which must have the processing 
power and infrastructure to accomplish the new tasks (i.e., the SSP must also provide 
SCP functionality). This way the SCP can accommodate a higher number of calls and 
is restricted to the user interaction functionality [Broadband Special Resource Function 
(B-SRF) capability]. The distribution of the SLP to the attached SSPs can sustain the 
additional processing required per call. 

Traffic in the signaling network is reduced by moving services closer to the cus- 
tomers, and the messages related to service control are handled locally. The overhead of 
downloading service programs is done off-line and does not impact signaling performance. 

The distribution of services to the switches does not affect the IN basic principle of 
distinguishing between enriched call control (Call Control/Service Switching Functions, 
CCF/SSF) and service intelligence (Service Control Function, SCF). The detection of IN 
call attempts is still determined at call control level, and following that, an invocation of 
IN facilities is done by the switch. The difference is now in the communication technology 
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Figure 2.5 Distributed IN architecture. 



between SSF and SCF, which is based on CORBA principles. Backward compatibility 
with traditional IN can be achieved by using IN/CORBA gateways, which allow for 
gradual introduction of distributed IN as advanced service islands. The distributed IN 
architecture is shown in Figure 2.5. In this figure, prefix B- is used with the IN functional 
entities to indicate the application of IN concepts to a broadband environment. 

Broadband infrastructure is not a mandatory requirement and the benefits of MAT/DOT 
techniques to IN apply also to a narrowband architecture. 

The following network elements are used in the network architecture: Service Creation 
System (SCS), SMS, Service Execution Node (SEN), Broadband Service Switching and 
Control Point (B-SS & CP), and Customer Premises Equipment. For broadband multime- 
dia services, the terminals need to have support to access switched broadband network 
(e.g., ATM). They need to have specialized hardware (e.g., ATM cards) and firmware (e.g., 
User to Network Interface - UNI signaling stack). MAT and CORBA can be applied to 
network physical entities including terminals. 

Services are developed and tested within SCE. The SMS provides service storage, 
service uploading to network elements, and service control capabilities (i.e., agent local- 
ization, alarm handling). The SEN is the physical element that joins the roles of the 
Broadband Service Control Point and Broadband Intelligent Peripheral. Broadband SSP 
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has the capability to locally execute services downloaded from the network and is named 
B-SS & CP. 

In distributed IN where CORBA can be used for message exchange, generic program- 
ming interfaces are available for developers. In this architecture, B-SCF, B-SDF, and 
B-SRF are implemented as CORBA-based software components allowing DPE’s location 
transparency and direct method invocation. 

There are several benefits of distributed IN architecture. The network elements can 
communicate in a homogeneous way. The SEN can be the contact point between the 
users and the network. The operator can choose a distributed, centralized service or 
mixed service. 

Interactive Multimedia Retrieval (IMR) is an integrated multimedia service within the 
framework of broadband IN. Broadband Video Telephone (BVT), is a real-time, multime- 
dia, two-party service that provides two geographically separated users with the capability 
of exchanging high-quality voice information, together with the transmission of high- 
quality video data. BVT is offered by Broadband-Integrated Services Digital Network 
(B-ISDN), which supports the facilities requested by the new generation of multimedia 
workstations. 

The BVT service uses mobility management procedures to enable users to register 
at different (fixed) terminals. In a manner similar to the IMR and BVT services, the 
realization of these procedures is based on DOT and MAT. 

MAs enable both temporal distribution (i.e., distribution over time) and spatial dis- 
tribution (i.e., distribution over different network nodes) of service logic. In multimedia 
services, the porting of services usually occurs between IN elements of different types 
(SSPs and SCPs), whereas in mobility services, the porting of services is usually between 
modules of the same type (SCPs). These two approaches are not alternative and can be 
combined; therefore, if multimedia services are offered to mobile users, then MAT can 
be widespread in the IN architecture in the most effective way. 



2.2 AGENT-BASED MIDDLEWARE 

Terminal and user mobility are important aspects of communications systems. Laptop com- 
puters, Personal Digital Assistants (PDAs), and mobile phones are the elements of mobile 
office. The Agent-based Mobile Access to Multimedia Information Services (AMASE) 
supports agent mobility. 

A mobility system that can be accessed by a user from any kind of terminal must 
have an appropriate device support and must be scalable, that is, the mobility system can 
be installed on different kinds of devices, especially mobile devices with strict resource 
constraints such as PDAs and mobile phones. A mobility system can be sized from a 
full-fledged system to a subsystem until it reaches a size and complexity that matches the 
constraints set by the devices involved and still provides all the required services. 

The distributed AMASE Agent Environment comprises several devices and nodes, 
each running one instance of the stand-alone AMASE Agent Platform, which can be 
scaled to fit into different device types. The agent system shown in Figure 2.6 consists 
of two layers, the Agents System (AS) and the communication facilities. Communication 
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Figure 2.6 Architecture of the AMASE system. 



facilities provide access to a broad range of underlying networks and handle the roaming 
between different kinds of networks. 

The AS layer provides a runtime environment for cooperative MAs. This layer allows 
agents to migrate from one AS to another, to access services available in the network, 
and to communicate with other agents. The Service Center of the Agent System is a 
fundamental component for mobile agent management and user mobility and is used for 
locating and accessing services and agents. 

The AMASE system and its supported agents are developed in Java. An agent system 
launcher supports loading a scaled version of the AS into a mobile device and executing 
it on different Java Virtual Machines (JVM). The launcher closely cooperates with a unit 
for agent system software update allowing for upgrading the AS’s software at least at 
start-up or upon request. An agent launcher is used for application allowing for more 
convenient and browser-like launching of agent-based applications by hiding all the Java 
and agent system specifics. 

The core of the AS is the Agent Manager (AM), allowing MAs access to the application- 
specific parts of the AS’s functionality via an agent API. The communication facilities 
are interfaced by AS’s Communication Manager (CM), and the communication facilities 
detect connection to available networks and their special services. The CM establishes 
the protocols for interagent communication, agent migration, and for accessing a Service 
Center and its Agent Directory (AD) via its protocol handlers. 
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The Persistent Storage area is either located in the persistent memory area of the 
underlying device, or on a magnetic medium. This area is needed to save agents and the 
agent system state and configuration. 

The CM comprises user and security managers that establish a user management and 
allow for the enforcement of access policies. An additional resource manager provides 
information about device utilization, for example, memory or agent population. A com- 
ponent for dynamic updates of the agents’ software allows for versioning and updates of 
agent classes. 

The AM is responsible for controlling the agent population of the agent system. AM 
allows for launching and termination of agents and provides them with the functionality 
needed for migration, communication, service access, and so on. In AMASE environment, 
there are MAs and system agents. MAs are created by application and they can roam 
within the network. They are not allowed to access system resources for security reasons. 
Usually these agents interact with the user for an initial configuration before they are 
launched into the network. They allow the user to perform remote operations without a 
constant network connection. 

MAs and system agents are supported by the AS. System agents can access system 
resources and become a mediator between the MAs and the system resources and the 
services they need to access. 

The AM cooperates with the user manager and the resource manager, which permits 
them to assign detailed access rights to agents. Both agent types are maintained separately 
by the AM, which supports a clearly defined type-dependent handling, for example, in case 
of a shutdown. Agents are registered with the local AM, and MAs are also automatically 
registered with the Service Center’s AD. 

In Figure 2.6, the CM connects the entire agent system to the communication facilities, 
which connect a device to the available networks. The CM surveys preconfigured ports on 
sockets provided by the communication facilities to receive incoming messages. Agents 
can be dispatched and handled by the AM. Each CM has access either to a local or 
remote router provided by the agent-related directories. This router helps CM to find and 
address the other agent systems. The CM is responsible for converting Java objects into 
byte streams and is involved in synchronous communication, which requires temporal 
suspension of agents. 

CM and communication facilities optimize communication and connection handling. 
The protocols consider network and device characteristics, and Quality of Service (QoS) 
information. Connections are physically closed during timeouts but kept open virtually. 
These operations that are transparent to the agents save connection costs and support 
disconnected operations and user mobility. The following communications mechanisms 
are provided by using the agent system communication manager, its protocol handlers, 
and the underlying communication facilities: 

• asynchronous one-way agent-to-agent messages; 

• synchronous two-way agent-to-agent messages based on Remote Procedure Call 

mechanisms; 
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• blackboards for local agent communication within agent systems - a blackboard is a 
data area where agents can leave information that may be read and removed by other 
agents under configurable access restrictions; 

• postbox messages for specified agents; this is a message queue that belongs to a 
single agent and which is located at a well-known location in the network that is 
known to both the message senders and the postbox owner; the owner agent can 
only read the box contents and remove the messages, and all other agents can drop 
messages. 

MAs are capable of migrating, which can occur at any time; thus, a mechanism is 
needed to determine an agent's current location. This mechanism is not necessary for 
asynchronous communication and communication based on blackboards and postboxes; it 
is inevitable for direct communication of agents. The Mobile Agent System Interoperabil- 
ity Facility (MASIF) specifies a Mobile Agent Facility (MAF) component MAFFinder, 
which is an abstract facility for mobile agent localization. MAFFinder is abstract because 
it does not specify how the agents are to be localized - only that a presence of such 
facility is required. Concepts for mobile agent localization include broadcast, forwarding, 
and directory service/home registry. 

AMASE system introduces a Service Center based on a directory service using general 
mobile agent execution cycle. MAs are restricted in their size and complexity owing to 
the costs of agent migration. MAs use services to execute the tasks required. The agents 
contact a facility in the agent system that provides a naming or trading service and passes 
information on the location of the requested services. This Service Center in AMASE 
system is based on the concept introduced by the Java Agent Environment (JAE). 

AMASE system introduces a ticket concept to pass information to MAs while keeping 
the actual migration and location information transparent. Mobile agent requesting a 
service from the Service Center receives a ticket shown in Figure 2.7. By calling useSer- 
vice (ticket), the MA uses the service provided, migrating to the respective agent system if 
it is not located in the same agent system. In addition to the information about home loca- 
tion. destination, and migration history, it is possible to store additional data in the ticket 
object, for instance, departure time, maximum number of connection retries, and priority 
information. The origin entry provides details about the creation and the starting point of 
the MA that is needed if the agent returns after having accomplished its task. Because of 
the user mobility and the disconnected operations, the originating device might be turned 
off and may become unreachable for the mobile agent. In this case, the permanent home 
entry gives an alternative address. The permanent home is an agent system at the service 
provider or the agent enabled home computer. 

The architecture of the Service Center shown in Figure 2.8 introduces a new mechanism 
for localizing MAs by using the AD. Whenever a MA requests a new service or migrates 
to another host, its position is updated in the Service Center. The agent location is stored 
in the AD. This is implemented as a Lightweight Directory Access Protocol (LDAP) 
server, with the Service Center holding an LDAP client for accessing the AD. 

In this approach, a MA's position is always known by the Service Center. The update 
of the agent’s position is embedded in the agent migration process; a migration is not 
completed before the update has been executed. This way the MAs can always be tracked. 
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Figure 2.7 An abstract ticket object. 




There are no message bursts caused by agent localization. The AD concept allows a seam- 
less integration into the facilities required for localization services for mobile agent use. 

The AMASE system allows the user to access individually configured services and 
data from different kinds of terminals, keeping transparent the details of the configuration 
and underlying mechanisms. The user profiles are in the profile directory similar to the 
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AD. A user profile contains information about the user’s preferences and data, display and 
security settings, and scheduling information and address books. The profile directory is 
a generic database for maintaining user information, which includes application-specific 
data. Customized agents adapted to application-specific needs can be created on the device 
the user is currently deploying. The user can specify types of services to be used without 
having to be aware of their location or current availability. 

The mobility middleware system is presented in Figure 2.9. The mobile agent, equipped 
with the service description and a specification of the preferred mechanism to return 
results, contacts the AD to localize the appropriate system agents that provide the required 
services. The agent obtains the ticket and migrates to the appropriate system agents and 
uses their services. Once the results are generated, the profile directory is used. If the user 
specified a type of terminal to deliver the results, the MA obtains the address from the 
profile directory and returns the results via the respective telecommunication service. On 
the other hand, if the user does not specify a method for returning the results, the MA 
decides which method to use. User and terminal profiles used with MAT create a flexible 
and device-independent user mobility. 

The users can become temporarily unreachable when the results are available. MAs 
allow the users to disconnect after specifying the service. If the method specified for 
returning the result is an asynchronous message (e.g., e-mail, fax), no feedback is required 
by the MAs. On the other hand, if the agent’s execution depends on the user’s feedback 
or if the return method is selected by the user after an initial notification, the MA can- 
not be terminated and must wait for user input to continue execution. The AMASE 
system introduces the kindergarten concept for an MA, which recognized that the tar- 
get user is currently unavailable, or, if the execution of the notification method failed 




Figure 2.9 The agent-based mobility middleware. 
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Figure 2.10 The mobile agent kindergarten concept. 



or timed out, to contact a kindergarten coordinator that checks if the system having 
last served the MA is capable of holding this agent until the user becomes available. 
In this case, the agent is suspended until further notice. The agent is instructed to 
migrate to a host providing a kindergarten storage. This server suspends the MA and 
resumes it when the user reconnects. The MA can also be moved to persistent stor- 
age until being resumed, which allows for managing a large number of MAs. The 
kindergarten concept shown in Figure 2.10 provides a mechanism for handling MAs 
belonging to disconnected users and forms the basis of mobility support deploying user 
and terminal profiles. 



2.3 MOBILE AGENT-BASED SERVICE 
CONFIGURATION 

MAT allows for object migration and supports Virtual Home Environment (VHE) in 
the Universal Mobile Telecommunications System (UMTS). VHE uses MAs in service 
subscription and configuration. 

UMTS supports QoS, the Personal Communication Support (PCS), and VHE. The 
VHE allows for service mobility and roaming for the user, which carries subscribed and 
customized services while roaming. During the registration procedure, the VHE enables 
the visited network to obtain the information about the user’s service provider, the user’s 
personalized service profile, and the identification about service capabilities to execute 
specific services. 

The VHE architecture shown in Figure 2.11 can be viewed as middleware layer that 
hides from the user the concrete network capabilities and differences in user and provider 
system capabilities. Service intelligence can be located inside the network within the 
Service Control and Mobility Management Platform (SC & MMP) or outside the network 
within the Universal Service Identification Module (USIM) of the end system. Service 
adaptation and media conversion is needed to cope with the diversity of end systems 
supporting personal mobility and QoS variations of different ANs supporting terminal 
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Figure 2.11 Virtual home environment. 



mobility. The enhancements of service control intelligence during service execution and 
dynamic subscription of a new third-party services should be allowed in the system. 

The UMTS environment shown in Figure 2.12 consists of a terminal, the AN, the 
SC & MMP, and the third-party service provider. A user registers at the terminal that 
presents services to the user. The user’s identification and authentication is handled by 
the UMTS Subscriber Identity Module (USIM). The network access of the terminal is 
managed by the access network. Fixed or mobile terminals are linked by the AN to the 
SC & MMP. The SC & MMP contains service logic and is responsible for the mobility 
management. Third-party service provides support supplementary services. A third-party 
service provider has a connection to one or more SC & MMPs and does not have its own 
mobility management facilities. 

A middleware layer is introduced in UMTS architecture in Figure 2.13. The middleware 
consists of Distributed Agent Environment (DAE), for example, Grasshopper, which is 
built on the top of DPE, for example, CORBA, and spans all potential end user systems 
and provider systems. The nodes provide agent environments through middleware system 




End user system Home provider system Other provider system Third party provider system 



Figure 2.12 The main components of the third-generation mobile communication system. 
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Visited MSC Gateway MSC Third party service provider 



Figure 2.13 The distributed agent environment spanning across UMTS end user and 

provider systems. 



to enable downloading and migration of MAs. MAs contain intelligence related to mobility 
management and service control (VHE control) and the end user application between the 
involved system nodes, including the Mobile Stations (MSs). 

In agent-based UMTS, a VHE-agent realizes the VHE concept; a Service Agent (SA) 
represents a provided service; a Terminal Agent (TA) allows the terminal to inform the 
provider system about its capabilities; and a Provider Agent (PA) realizes a trader within 
the provider system, which manages all supported services (SA), that is, maintains an 
overview of all available services within the provider domain. 

The VHE allows individually subscribed and customized services to follow their associ- 
ated users wherever they roam. The VHE-agent follows the user to the domain to which 
the user is roaming. At every domain, the VHE-agent provides the user’s subscribed 
services and configurations. 

Agencies in the MS allow dynamic distribution of mobility management and service 
control intelligence to be downloaded dynamically from the MS into the (visited) provider 
system and from the (visited) provider system onto the MS, to be distributed within one 
provider system at the most appropriate location and to be distributed between different 
provider systems. The end systems through the USIM can take an active part in mobility 
management and service control. 

The PA residing in every provider domain contains the knowledge of all services 
provided by this domain. The PA is designed as a trader in MASIF. The PA is the 
initial contact point of the VHE-agent after the user is roamed to a new domain. The 
PA is designated as a stationary agent since its task makes the migration of this agent 
not necessary. 

The SAs are located within the provider domain, or at the third-party service provider 
domains, or at the user’s terminal. The Converter Agents (CAs) at the provider agency are 
responsible for converting incoming and outgoing calls on the basis of user and terminal 
requirements. This allows for support of services on terminals that cannot originally 
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present the service such as reading out a fax or e-mail on a telephone. The knowledge 
of the terminal capabilities is maintained by the TA. Different types of agents and their 
communication relationships are shown in Figure 2.14. 

The VFIE-agent can migrate from the provider domain from which the user comes to 
the provider domain to which the user is roaming. Another possibility is to store a major 
copy of the VFIE-agent within the home service provider domain. Whenever the user 
roams to a new provider domain, a copy of the VFIE-agent migrates to this domain. The 
VFIE-agent can also be stored on the terminal agency. The VHE-agent migrates from the 
terminal agency to the provider agency when the user roams to a new domain. 

Dynamic subscription allows a user to subscribe to and to unsubscribe services. The 
subscription component presents the entire set of provided services to the user. The 
information can be retrieved during the registration procedure after the user roamed to a 
new provider, and the subscription component requests the provider to get information 
about provided services. The services of a new provider can also be concatenated to the 
service list that is stored by the VHE. The network can provide a roaming broker that can 
be contacted by the subscription component to get the information about service providers. 

The abstract service subscription is present at the provider where the user roams. 
The user registers at the new provider, and the VHE-agent contacts the PA to receive a 
subscription interface to process the VHE request. The PA finds an SA that corresponds 
to the abstract service description. The PA returns a reference to the existing SA that 
matches with the service description. If there is no SA matching service description, the 
PA finds a corresponding agent at different service providers. The PA explores possibilities 
illustrated in Figure 2.15. The current service provider can contact other service providers, 
or a roaming broker can be used, or the home service provider can provide a reference 
to the service agent. 

The User Interface Agent (UIA) is responsible for the presentation of the SA at 
the user’s terminal. The UIA provides terminal-dependent service presentation capabil- 
ities. The same service can be represented by many UIAs for terminals with different 
capabilities. The VHE-agent decides which UIA download to the terminal as shown in 
Figure 2.16. The VHE-agent contacts the TA, which resides on the terminal agency, that 
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Third party service provider region 



Home service provider region 




Visited service provider region 

<* 





MSC agency 



1 - Provider agent tries to find a service 
agent in its own domain and with capabilities 
that can be presented at the terminal of 

the user 

2 - Provider agent contacts the Roaming 
Broker (RB).The RB tries to find a matching 
service agent 

3 - Provider agent contacts the home 
service provider to get access to the 
service agent 



Figure 2.15 Service access strategies. 




1 - VHE-agent requests the Terminal Agent to 
get properties of the terminal. This information 
will be sent by the TA to the VHE-agent. 

2 - The VHE-agent will request the provider 
agent. 

3 - To find a corresponding UIA. 

4 - If a UIA was found, it will be downloaded to 
the terminal agency. 

Figure 2.16 The UIA selection procedure. 
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is, mobile station. This TA is device dependent and contains technical information about 
the terminal. The VHE-agent requests the TA to get this information. The returned val- 
ues are used by the VHE-agent to find a corresponding UIA. The service subscription 
procedure is used to locate the UIA. 



2.4 MOBILE AGENT IMPLEMENTATION 

MAs can be implemented in Java programming language. Additional features and mech- 
anisms supported and envisioned in Jini programming language allow for implementation 
of mobile devices in practical systems. 

The Jini vision introduced by Edwards allows for devices and software services to work 
together in a simple, fast, and reliable manner. The requirements for devices and software 
specify robust software infrastructure developed to support reliable systems. The devices 
must be easy to use and administer, and should work instantly after being connected. The 
software systems must be evolvable, and software services and devices should permit their 
use without reconfiguration of the network. These devices form spontaneous communities 
within dynamic networking. 

Mobile code is used in several structures to support mobile applications. In Java pro- 
gramming language, applets are used for small applications to be installed automatically 
wherever they are needed and removed when their users do not need them. In the agent 
paradigm, small, autonomous bits of code travel to search for desired data. The mobile 
code is used for performance and autonomy. Agents can provide a better performance 
as the code moves closer to data in the network. Agent autonomy allows the user to 
log off or shut down the machine, and the agent that left the originator computer can 
continue to ran even if the originator disconnects. Java RMI allows for building various 
distributed systems and can be used for automatic application installation or for building 
agent-based systems. Mobile code in RMI is used for object-oriented networked systems 
and it supports evolvable implementations of remote objects and new implementations of 
parameter and return types. Jini uses mobile code to achieve maintenance, evolvability, 
and ease of administration for networked devices and services. Jini is layered atop RMI, 
allowing all the benefits of mobile code to be used by programs in Jini. 

Jini supports spontaneously created self-healing communities of services, and it is 
based on the concepts of discovery, lookup, leasing, remote events, and transactions. 

Jini uses discovery protocols to find the available lookup services. The Multicast 
Request Protocol is used to find the active lookup services after an application or service 
becomes initiated. Lookup services announce their existence in the system by using the 
Multicast Announcement Protocol. An application or service talks to the lookup service 
by using the Unicast Discovery Protocol. 

The lookup service is a process that has semantic information about available services. 
The service items have proxy objects and attributes describing these services. 

Jini concept of leasing allows the resource to be loaned to a customer for a fixed period 
of time rather than granting access to a resource for an unlimited amount of time. This 
ensures that the communities of services are stable, self-healing, and resilient to failures, 
errors, and crashes. 
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Jini uses remote events to allow services to notify each other about the changes in 
their state. These are messages sent as asynchronous notifications directly to a software 
component and handled outside the normal flow of control of the component. 

Computations involving multiple services reach safe and known state by using transac- 
tions in Jini. Transactions provide atomicity, consistency, isolation, and durability to data 
manipulations. All the operations under transactions are executed as an atomic operation. 
Transactions ensure state consistency after completion. Transactions are isolated during 
execution; they do not affect one another until completion. Transaction durability makes 
the changes permanent. 

2.5 SUMMARY 

MAT uses the capabilities provided by machine-independent, interpreted languages like Java 
to deploy a framework in which applications can roam between network nodes maintaining 
their execution status. MAT platforms are often based on a CORB A DPE layer, which allows 
distributed applications to dynamically reconfigure their layout according, for instance, to 
processing needs. This way certain MAs may have a CORBA interface enabling them to 
exploit the facilities offered by the distributed objects communication infrastructure. 

The introduction of DOT and MAT at the service design and deployment level allows 
for reusability for easy and rapid deployment of services, extensibility towards new and 
updated services, and flexibility of service design. 

The AS layer provides a runtime environment for cooperative MAs. This layer allows 
agents to migrate from one AS to another, to access services available in the network, and 
to communicate with other agents. The Service Center of Agent System is a fundamental 
component for mobile agent management and user mobility and is used for locating and 
accessing services and agents. 

MAT allows for object migration and supports VHE in the UMTS. VHE uses MAs in 
service subscription and configuration. 

The UMTS environment consists of a terminal, the AN, the SC & MMP, and the 
third-party service provider. 

In agent-based UMTS, a VHE-agent realizes the VHE concept; an SA represents a pro- 
vided service; a TA allows the terminal to inform the provider system about its capabilities; 
and a PA realizes a trader within the provider system, which manages all supported services 
(SA), that is, maintains an overview of all available services within the provider domain. 



PROBLEMS TO CHAPTER 2 

Mobile agent-based service implementation, middleware, and configuration 

Learning objectives 

After completing this chapter, you are able to 

• demonstrate an understanding of distributed object technology; 

• discuss what is meant by intelligent agents; 
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• demonstrate an understanding of agent-based service implementation; 

• explain how to handle service requests; 

• explain temporal and spatial distribution of service logic; 

• discuss multimedia services; 

• demonstrate an understanding of a mobility system; 

• explain what agent system, agent manager, and communication manager are; 

• explain mobility middleware system; 

• demonstrate an understanding of the Universal Mobile Telecommunications System 
(UMTS); 

• discuss what an agent-based UMTS is; 

• demonstrate an understanding of the VHE concept; 

• explain how the VHE-agent migrates in the system; 

• explain dynamic subscription of services; 

• demonstrate an understanding of mobile agent implementation in Java program- 
ming language; 

• demonstrate an understanding of mobile agent implementation in Jini program- 
ming language. 

Practice problems 

2. 1 : What is the role of DPE in DOT? 

2.2: What are the functions of Intelligent and Mobile Agents? 

2.3: What distribution of service logic is enabled by Mobile Agents? 

2.4: What are the requirements for a mobility system? 

2.5: What is the role of the Agent System layer? 

2.6: Where is the Persistent Storage located and why is it needed? 

2.7: What is supported by the UMTS? 

2.8: What are the elements of the UMTS environment? 

2.9: How is the VHE concept realized in agent-based UMTS? 

2.10: What is the role of dynamic subscription? 

2.11: What is the role of the User Interface Agent (UIA)? 

2.12: What are applets used for in Java programming language? 

2.13: What is the concept of Jini programming language? 



Practice solutions 

2.1: DOT provides a DPE to enable designers to create object-oriented distributed appli- 
cations, which are not necessarily aware of the physical layout of the underlying 
network structure hidden by platform services. 

2.2: Intelligent Agents have the ability to learn and react. MAs can migrate between 
different hosts, execute certain tasks, and collaborate with other agents. 

2.3: MAs enable both temporal distribution (i.e., distribution over time) and spatial 
distribution (i.e., distribution over different network nodes) of service logic. 

2.4: Mobility system that can be accessed by a user from any kind of terminal must 
have an appropriate device support and must be scalable, that is, the mobility system 
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can be installed on different kinds of devices, especially mobile devices with strict 
resource constraints such as PDAs and mobile phones. A mobility system can be 
sized from a full-fledged system to a subsystem until it reaches a size and complexity 
that matches the constraints set by the devices involved and still provides all the 
required services. 

2.5: The AS layer provides a runtime environment for cooperative MAs. This layer 
allows agents to migrate from one AS to another, to access services available in 
the network, and to communicate with other agents. The Service Center of AS is a 
fundamental component for mobile agent management and user mobility, and it is 
used for locating and accessing services and agents. 

2.6: The Persistent Storage area is either located in the persistent memory area of the 
underlying device or on a magnetic medium. This area is needed to save agents 
and the agent system state and configuration. 

2.7: UMTS supports QoS, the PCS, and VHE. 

2.8: The UMTS environment consists of a terminal, the AN, the SC & MMP, and the 
third-party service provider. 

2.9: In agent-based UMTS, a VHE-agent realizes the VHE concept; an SA represents a 
provided service; a TA allows the terminal to inform the provider system about its 
capabilities; and a PA realizes a trader within the provider system, which manages 
all supported services (SA), that is, maintains an overview of all available services 
within the provider domain. 

2.10: Dynamic subscription allows a user to subscribe to and to unsubscribe services. 
The subscription component presents the entire set of provided services to the user. 

2.11: The UIA is responsible for the presentation of the SA at the user’s terminal. The 
UIA provides terminal-dependent service presentation capabilities. The same service 
can be represented by many UIAs for terminals with different capabilities. 

2.12: In Java programming language, applets are used for small applications to be installed 
automatically wherever they are needed, and removed when their users do not 
need them. 

2.13: Jini supports spontaneously created self-healing communities of services and is 
based on the concepts of discovery, lookup, leasing, remote events, and transactions. 
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Wireless local area networks 



Virtual LANs provide support for workgroups that share the same servers and other 
resources over the network. A flexible broadcast scope for workgroups is based on 
Layer 3 (network). This solution uses multicast addressing, mobility support, and the 
Dynamic Host Configuration Protocol (DHCP) for the IP. The hosts in the network are 
connected to routers via point-to-point connections. The features used are included in 
the IPv6 (Internet Protocol version 6) protocol stacks. Security can be achieved by using 
authentication and encryption mechanisms for the IP. Flexible broadcast can be achieved 
through enhancements to the IPv6 protocol stack and a DHCP extension for workgroups. 

Orthogonal Frequency Division Multiplex (OFDM) is based on a mathematical concept 
called Fast Fourier Transform (FFT), which allows individual channels to maintain their 
orthogonality or distance to adjacent channels. This technique allows data symbols to 
be reliably extracted and multiple subchannels to overlap in the frequency domain for 
increased spectral efficiency. The IEEE 802.11 standards group chose OFDM modulation 
for wireless LANs operating at bit rates up to 54 Mbs -1 at 5 GHz. 

Wideband Code Division Multiple Access (WCDMA) uses 5 MHz channels and sup- 
ports circuit and packet data access at 3 84 kb s~' nominal data rates for macrocellular wire- 
less access. WCDMA provides simultaneous voice and data services. WCDMA is the radio 
interface technology for Universal Mobile Telecommunications System (UMTS) networks. 

Dynamic Packet Assignment (DPA) is based on properties of an OFDM physical layer. 
DPA reassigns transmission resources on a packet-by-packet basis using high-speed receiver 
measurements. OFDM has orthogonal subchannels well defined in time-frequency grids, 
and has the ability to rapidly measure interference or path loss parameters in parallel on all 
candidate channels, either directly or on the basis of pilot tones. 

3.1 VIRTUAL LANs 

Virtual LANs provide support for workgroups. A LAN consists of one or more LAN 
segments, and hosts on the same LAN segment can communicate directly through Layer 2 
(link layer) without a router between them. These hosts share the same Layer 3 (network 
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layer) subnet address, and communication between the hosts of one LAN segment remains 
in this segment. Thus Layer 3 (network layer) subnet address forms a broadcast scope 
that contains all hosts on the LAN segment. 

The workgroups are groups of hosts sharing the same servers and other resources 
over the network. The hosts of a workgroup are attached to the same LAN segment, and 
broadcasting can be used for server detection, name resolution, and name reservation. 

In a traditional LAN the broadcast scope is limited to one LAN segment. Switched LANs 
use a switch infrastructure to connect several LAN segments over high-speed backbones. 
Switched LANs share the Layer 3 (network layer) subnet address, but offer an increased 
performance compared to traditional LANs, since not all hosts of a switched LAN have to 
share the bandwidth of the same LAN segment. LAN segments connected over backbones 
allow for distribution of hosts over larger areas than that covered by a single LAN segment. 

Traditional switched LANs require a separate switch infrastructure for each workgroup 
in the environment with several different workgroups using different LAN segments. 
Virtual LANs are switched LANs using software configurable switch infrastructure. This 
allows for creating several different broadcast scopes over the same switch infrastructure 
and for easily changing the workgroup membership of individual LAN segments. 

The disadvantage of virtual LANs is that a switch infrastructure is needed and admin- 
istration includes Layers 2 and 3 (link and network). A desirable solution involves only 
Layer 3 (network) and does not require special hardware. 

Kurz et al. propose a flexible broadcast scope for workgroups based on Layer 3 (net- 
work). This solution uses multicast addressing, mobility support, and the DHCP for the 
IP. The hosts in the network are connected to routers via point-to-point connections. The 
features used are included in the IPv6 protocol stacks. Security can be achieved by using 
authentication and encryption mechanisms for the IP. Flexible broadcast can be achieved 
through enhancements to the IPv6 protocol stack and a DHCP extension for workgroups. 

In IPv6, a special address range is reserved for multicast addresses for each scope, and 
a multicast is received only by those hosts in this scope that are configured to listen to 
this specific multicast address. To address all hosts in a certain scope with a multicast, the 
multicast must be made to the predefined all-nodes address, to which all hosts must listen. 
When existing software using IPv4 (Internet Protocol version 4) is migrated to IPv6, the 
IPv4 broadcasts are changed to multicasts to the all-nodes address, as this is the simplest 
way to maintain the complete functionality of the software. 

IPv6 multicasting can be used to form the broadcast scope of a workgroup. The 
workgroup is the multicast group, whose hosts listen to the same multicast address, the 
workgroup address. A host can listen to several multicast addresses at the same time and 
can be a member of several workgroups. 

Multicasting exists optionally for IPv4 and is limited by a maximum of hops. The 
multicast in IPv6 is limited by its scope, which is the address range. 

In a virtual LAN, the workgroup membership of a host is determined by configuration 
of the switches. Kurz et al. propose that a host has to determine its workgroups and 
their corresponding multicast addresses. Different workgroups are separated in Layer 3 
(network) since each host has the possibility to address a specified subset of hosts of the 
network using multicasting. All hosts can be connected directly to the routers, and the 
members of different workgroups can share the same LAN segment. 
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The administration of the workgroups is designed by storing the information about 
hosts and their workgroups in a central database in a DHCP server. The information is 
distributed by using the Dynamic Host Configuration Protocol version 6 (DHCPv6). 



3.1.1 Workgroup management 

In a workgroup address configuration, the host sends a DHCP Request with a Workgroup 
Address Extension to the DHCP Server. The DHCP Server replies with a Workgroup 
Address Extension containing all workgroup addresses assigned to this host. After receiv- 
ing the workgroup addresses, the host sends the Internet Control Message Protocol 
version 6 (ICMPv6) Group Membership Report to each of its workgroup addresses to 
inform the multicast routers about its new membership in these multicast groups. 

After learning its workgroup addresses, the host has to configure its interfaces to listen 
to these multicast addresses. The host has to change all outgoing multicasts to the all- 
nodes address (which are equivalent to IPv4 broadcasts) to multicast to the workgroup 
address of the host. This can be done by changing the IPv6 stack to intercept all outgoing 
multicasts to the all-nodes address and to change this address to the workgroup addresses 
of the host. If the host is a member of several workgroups, the multicast has to be sent 
to all workgroup addresses of the host. 

The purpose of DHCP is to provide hosts with addresses and other configuration 
information. DHCP delivers the configuration data in extensions that are embedded in 
request, reply, or reconfigure messages. The request message is used by the client to 
request configuration data from the server, and the reply message is used by the server to 
return the requested information to the client. If there is a change in the DHCP database, 
the server uses the reconfigure message to notify the client about the change and to start 
the new request reply cycle. 

Kurz et al. introduce a DHCP Workgroup Address Extension to deliver workgroup 
addresses to the host. In a DHCP Request the client must set the workgroup count to zero, 
must not specify any workgroup addresses, and must specify its node name. In a DHCP 
Reply the server must set the workgroup count to the number of workgroup addresses 
existing for this client, include all workgroup addresses existing for this client, and use 
the client’s node name. In a DHCP Reconfigure the server must set the workgroup count 
to zero, must not specify any workgroup addresses, and must use the client's node name. 

Mobile hosts can be the members of workgroups. The Internet draft Mobility Support 
in IPv6 proposes that a mobile host attached to a network segment other than its home 
segment continues to keep its home address on the home segment and forms a global 
care-of address for its new location. The binding update options included in IPv6 packets 
are used to inform correspondent hosts as well as the home agent, a router that is on the 
same segment as the home address of the mobile host, about its new care-of address. After 
the home agent is informed about the new care-of address of the mobile host, the home 
agent receives packets on the home segment addressed to the mobile host and tunnels 
them to the care-of address of the mobile host. 

Kurz et al. propose enhancements to the Internet draft Mobility Support in IPv6 for a 
mobile workgroup member to send or receive multicast packets from its home network 
and to participate in the multicast traffic of its group. If a mobile host leaves the scope 
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of a multicast group it joined, the home agent must forward packets sent to the home 
address of the mobile host and also all packets sent to the concerned multicast address. 
The mobile host has to be able to send packets to the multicast address of its workgroup, 
even though it is outside the scope of this address. This can only be done by tunneling 
the packets to a host inside the scope of the multicast address and resending them from 
that host. Since the home agent is on the segment associated with the home address of 
the mobile host, the task of resending multicasts of a mobile host can also be taken over 
by the home agent. 

The Internet draft Mobility Support in IPv6 proposes a binding update option, which 
is used to notify the home agent and other hosts about a new care-of address of a mobile 
host. The original home link local address of the mobile host has to be specified in the 
source address field in the IP header of the packet containing the binding update option. 
It can also be specified in the home link local address field in the binding update option, 
but a multicast address cannot be specified this way. Kurz et al. introduce an optional 
field for a multicast address in the binding update option to inform the home agent about 
workgroup addresses to which the mobile host listens. A field for the workgroup address 
is used to indicate that there is a multicast group address specified in the option. 

3.1.2 Multicast groups 

A mobile host that left the scope of one of its multicast groups sends a binding update 
option to its home agent to inform it about the new care-of address. A mobile host has 
to specify its multicast group address in the binding update option. If the mobile host is 
a member of several multicast groups, it has to send a binding update option for each of 
its multicast groups. 

A home agent notified by a binding update option about a multicast address for a 
mobile host must join this multicast group and handle packets with this multicast address 
in the destination address field in the same way as the packets with the home address 
of the mobile node in this field. The mobile host must treat a received encapsulated 
multicast packet in the same way as the packet received directly. The mobile host must 
not send a binding update option to the address specified in the source address field of 
an encapsulated multicast packet. 

When sending a multicast packet to its multicast group, the mobile host has to use its 
home address in the source address field of the multicast packet and tunnel this packet to 
its home agent. When a home agent receives an encapsulated multicast packet in which 
the source address field is the same as the home address of a mobile host served by it, 
the home agent has to act like a router, receiving this multicast packet from the home 
segment of the mobile host and additionally forwarding it to the home segment of the 
mobile host. 

This way of providing mobile workgroup members with the possibility to leave the 
scope of the multicast address has a drawback that it may not scale well in the case of 
broadcast intensive workgroup protocol stacks, since all the broadcasting traffic, which 
was intended to remain in the limited area, has to be forwarded to the mobile node. 
If many workgroup members use the possibility of global mobility, there is a risk of 
overloading the Internet with workgroup broadcasting traffic. 





